DAOS-19265 pool: refine pool_discard() target validation#18643
DAOS-19265 pool: refine pool_discard() target validation#18643liuxuezhao wants to merge 2 commits into
Conversation
|
Ticket title is 'metadata storage doesn't seem to improve even after deleting containers in a pool (when the pool hit DER_NO_SPACE issue during rebuild operation)' |
liuxuezhao
force-pushed
the
lxz/discard_refine
branch
2 times, most recently
from
64761ce to
aaddb1c
Compare
pool_discard() previously sent the POOL_TGT_DISCARD RPC to target engines using the caller-supplied pool_target_addr array as-is, without validating it against the pool map. On the target engine side, ds_pool_tgt_discard_ult() then relied on its own (possibly stale) local pool map, using ex_status = PO_COMP_ST_UP | PO_COMP_ST_UPIN | PO_COMP_ST_DRAIN passed to ds_pool_thread_collective(), to exclude targets from the discard. When the target engine did not yet have the latest pool map, this could lead to targets holding useful data being discarded, or targets needing a discard being skipped. Add pool_discard_filter_tgts() to validate/filter the input pool_target_addr array against the pool service leader's authoritative pool map before building the POOL_TGT_DISCARD RPC: - for REINT, only keep targets currently in PO_COMP_ST_DOWN or PO_COMP_ST_DOWNOUT. - for EXTEND, only keep targets currently in PO_COMP_ST_NEW, or targets not yet present in the pool map at all (brand new ranks/targets being added can't hold pool data yet, so they are always safe to discard). On the target engine side, ds_pool_tgt_discard_ult() no longer needs to exclude targets based on its local pool map status, since the RPC input list has already been validated and filtered by the leader. pool_child_discard() already restricts the discard to targets present in the RPC's target list. Signed-off-by: Xuezhao Liu <xuezhao.liu@hpe.com>
liuxuezhao
force-pushed
the
lxz/discard_refine
branch
from
aaddb1c to
74cb258
Compare
|
Test stage Functional Hardware Medium Verbs Provider MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-18643/4/execution/node/1768/log |
|
Test stage Functional Cluster Box Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-18643/4/execution/node/1748/log |
NiuYawei
left a comment
NiuYawei
left a comment
There was a problem hiding this comment.
LGTM. Aside from the discard, will the reint operation work without issues if the reintegrated rank doesn't have an up-to-date pool map? When will the pool map (with the reintegrated rank in the UP state) be propagated to the target rank?
After PS leader change the pool map, the reint engine's staus will be UP and the new pool map will bcast to it. |
3 participants
pool_discard() previously sent the POOL_TGT_DISCARD RPC to target engines using the caller-supplied pool_target_addr array as-is, without validating it against the pool map. On the target engine side, ds_pool_tgt_discard_ult() then relied on its own (possibly stale) local pool map, using ex_status = PO_COMP_ST_UP | PO_COMP_ST_UPIN | PO_COMP_ST_DRAIN passed to
ds_pool_thread_collective(), to exclude targets from the discard. When the target engine did not yet have the latest pool map, this could lead to targets holding useful data being discarded, or targets needing a discard being skipped.
Add pool_discard_filter_tgts() to validate/filter the input pool_target_addr array against the pool service leader's authoritative pool map before building the POOL_TGT_DISCARD RPC:
On the target engine side, ds_pool_tgt_discard_ult() no longer needs to exclude targets based on its local pool map status, since the RPC input list has already been validated and filtered by the leader. pool_child_discard() already restricts the discard to targets present in the RPC's target list.
Steps for the author:
After all prior steps are complete: